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REMARKS 

By this amendment, the specification has been amended, claims 2, 5, 7, 10, and 12 
have been cancelled, and claims 3, 6, 8, and 13 have been amended. Both clean and 
marked-up copies of amended specification sections and claims are included herewith. 
The Examiner indicated that there were many informal errors in the specification. 
Numerous grammatical corrections were made to the specification. It is believed that all 
informal errors which would interfere with readability and understanding have been 
corrected. 

The Examiner and the undersigned had a brief and highly productive telephone 
conference at approximately 4:30 p.m. on Monday, 12 March 2001. We discussed the 
desired format for making corrections to specifications under the new rules. Every 
attempt has been made to comply with the new rules and to make the corrections easy to 
understand. 

The input and co-operation of the Examiner in this regard are greatly appreciated. 

It is, however, noted that a large portion of the specification did not contain line 
numbers. The reference line numbers used in the corrections were obtained by coxmting 
down fi-om the top, including blank lines. Because entire paragraphs are now to be 
included, it is hoped that there will be minimal opportimity for confusion. 

Claims 1 through 24 stand rejected. 

The Examiner objected to Claim 11 for an informal error. The Examiner correctly 
noticed that Claim 1 1 should have been dependent from Claim 10 and not Claim 9. 
However, as explained below, Claim 9^has been cancelled. This alters the dependency 
relationship between Claims 9 and 1 1 so that Claim 1 1 now depends fi-om Claim 9 as was 
vmtten. Thus, there is no longer a need to amend Claim 1 1 . 

The Examiner objected to Claims 3, 6, 8, 1 1, and 13 under 35 CFR 1.75(c) as 
being of improper dependent form for failing to further limit the subject matter of a 
previous claim. Claims 2, 5, 7, 10, and 12 have been cancelled and Claims 3, 6, 8, and 13 
have been amended. The result will resolve the improper dependence objected to by the 
Examiner. 
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This invention provides an integrated system and method for pre-processing 
electronic data requests before these requests are sent to an order processing system. Pre- 
processing performs the functions of correcting erroneous requests, rejecting requests the 
order processing system cannot process, and planning and scheduling to determine if a 
given material is available for delivery in a given quantity and delivery date. 

Pre-processing does not perform order fulfillment. Order fulfillment is performed 
by an order processing system. Pre-processing, by filtering out bad requests, substantially 
speeds up order fulfillment systems. 

The Examiner rejected Claims 1-24 under 35 USC 102(e) as being clearly 
anticipated by U.S. Patent 6,058,373 to Blinn et al. and also by U.S. Patent 6,023,683 
to Johnson et al. Applicants respectfully traverse those rejections for the reasons below. 

Blinn and Johnson disclose order processing syste^} The claimed invention 
claims a^pre-processing system. )A pre-processing system takes the data that will later be 
repassed to an order processing system (see Claim 1, line 9) after making various checks on 
^ — -"-^ the data (see Claim 1, line 5). One major function of a pre-processor is^e convert 

incoming data into the format to be used by an order processing system. The claimed 
^.^^J::^::^^ invcntlon, imlike those of Blinn and Johnson, does not fill any orders. 

The Examiner cites figures 13 and 15 of Blinn in support of the rejection. Figure 
13 of Blinn clearly discloses an order processing system not a pre-processing system. See 
blocks 1302 ("Consumer Accesses Merchandizing System"), 1304 ("Consumer Views 
Virtual Store"), and all others down to 1340 ("Fulfill Order"). Figure 15 shows how the 
order processing system of Blinn processes the order. 

Johnson discloses an order processing system designed to fill orders made fi-om 
catalogs. Johnson, thus, discloses a system as inapplicable as that of Blinn to the claimed 
invention. Both BUnn and Johnson assume good data in the proper format. The claimed 
y/T^^ \invention provides that good data in proper format. 

^ Both Blinn and Johnson assume the data they will receive is in proper format. 

Blinn teaches a key-value pair structure that permits a wide variety of formats. See Blinn 
at Column 2, lines 56-61. Blinn does not contain any error-handling functions in the event 
incoming data is in some format the program cannot handle. See the figures for Blinn and 
the outline at Column 5, lines 19-52. See Johnson, Column 5, lines 28-34 and lines 66 
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through Column 5, line 14 wherein the data is received from a database via an interface 
that. Column 5, starting at line 66, "preferably comprises" certain fields. Johnson makes 
no provisions for what happens if the data does not contain those fields. 

Attention of the Examiner is called to explicit language in the Claims of the 
claimed invention, such as. Claim 16, lines 3 and 4 wherein the claimed invention 
"receiv[es] electronic sales data; translat[es] the electronic sales data to an internal format" 
and so forth. Finally, the claimed invention "transmit[s] the designated portions of the 
internal format data to the order processing system". In other words, the pre-processor 
works in conjunction with, but not as a replacement for, an order processing system. 

The closest the claimed invention comes to order processing is that part of the 
invention that does a look-ahead to see if it is possible to fill an order. It does not fill the 
order. It just checks to see if the order cannot be filled. This is an important difference 
because the claimed invention wdll prevent an order processing system from attempting to 
fill an order that cannot be filled. 

In view of the foregoing, it is respectfiiUy requested that the application be 
reconsidered, that claims 1, 3, 4, 6, 8, 9, 1 1, and 13 through 24 be allowed, and that the 
application be passed to issue. 

Should the Examiner find the application to be other than in condition for 
allowance, the Examiner is requested to contact the imdersigned at the local telephone 
number listed below to discuss any other changes deemed necessary in a telephonic or 
personal interview. 

A provisional petition is hereby made for any extension of time necessary for the 
continued pendency during the life of this application. Please charge any fees for such 
provisional petition and any deficiencies in fees and credit any overpayment of fees to 
Attomey's Deposit Account No. 09-0456. 
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APPENDIX A 
CORRECTIONS TO SPECIFICATIONS 
Page 3 starting at line 14. 

Several patents relate to the pre-processing of presentation, docximents, and the like. 
These pre-processing systems are not, however, directly applicable to EDI and have 
shortcomings with respect to EDI applications. U.S Pat. N. 5,577,258 to Cruz et al. 
discloses an apparatus and method for pre-processing multimedia presentations to be 
delivered to customers such that delays due to interactive response time [is] are virtually 
eliminated. 

Page 4 starting at line 14. 

These patents are not directly applicable to EDI, and therefore do not provide or teach 
that there is an intelligent editor v^thin the customer order fulfillment system, or that post- 
processing modifications can be made to a customer order through the order fulfillment 
system. It is therefore an object of the present invention [is] to provide an integrated 
system and method for pre-processing electronic data requests before they are sent to an 
order processing system that provides a planning and forecasting engine that determines if 
[a] material is available for a given quantity and delivery date. These systems also do not 
enable corrections to be made to electronic data requests before they are sent to an order 
processing system. Nor do these systems allow electronic data requests to be rejected so 
that they are not sent to an order processing system when certain criteria specified within 
the electronic data request cannot be satisfied. 

Page 5 starting at line 2. 

It is therefore an object of the present invention [is] to provide an integrated 
system and method for pre-processing electronic data requests before they are sent to an 
order processing system. 

Page 14 starting at line 8. 

Figure 4 shows a functional flow diagram of the pseudo-sales order 
workbench 206. When ESO errors are encountered, workflow items are 
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created by the SAP Workflow, as indicated in function block 402. The 
workflow items are sent to the in-basket of the responsible person. When the 
work item is executed, as shown in function block 401, the work flow is 
displayed on a user terminal, as indicated by step 407. ESOs can also be 
displayed from the SAP workflow 402 that satisfy selection criteria that a user 
inputs into display block 403. Work flow messages are created imder pre- 
defined conditions and routed to the responsible person for action. [The 
responsible person] Responsible persons can view and execute their messages from their 
SAP Office Inbox (not shown). When the message is executed, the user is branched to the 
appropriate application to correct the condition, hi a preferred 
embodiment of the present invention, a workflow message is created when the 
order interceptor 201 encounters an error or determines that a manual review 
of the ESO is required. The user can also input selection criteria via the [an] 
input screen, as shown in step 403, to display ESOs that satisfy the selection 
criteria, as shown in function block 401 . The ESOs are stored in accordance 
with the SAP AG Corp. ESO tables ESO Control 404, ESO Data 405, and 
ESO Status 406. These tables validate the ESO structure, and pass control to 
ALE where the ESO can be processed into the appropriate business object, 
such as a sales order or a purchase order acknowledgment, etc. The error message table 
415 displays the error messages, as shown in function block 
408. Once the error messages have been displayed, the user can also view the 
fields 409 associated with the ESOs on the pseudo-sales order workbench 206, 
as shown in function block 409. The user can also perform various operations 
on the ESO, as indicated in function block 410. A test is then made in decision 
block 41 1 to determine if the ESO complies with the configuration rules and 
updates. If the ESO does not satisfy the configuration rules, a message is sent 
to the Pseudo-sales [order] Order Workbench, as shown in function block 412. If the ESO 
satisfies all configuration rules and updates, then the ESO is updated in 
tables 404, 405, 406 and 415. The process returns, as shown in fimction block 
414. If the user specified selection criteria is via display 403, then the return is to 
the user's display terminal 403. If the SAP workflow 402 created the work 
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item, then the return is back to SAP workflow 402. 
Page 21 starting at line 16. 

If pre-processor module 603 detects an error or manual review condition, the workflow 
module 605 creates a workflow that is made available to the in-basket of the responsible 
person. Once the work item is executed, the customer purchase order workbench module 
607 [is] provides a display to a user terminal. The user interface is modeled after the 
incompletion log for processing sales orders. The initial screen will display a list of 
messages identifying why the request was held along with key information from the ESO's 
control and data record segments. If the user is authorized, each item in the list can be 
executed and taken to the appropriate screen to correct or review the data. After each 
correction, the ESO is reprocessed by pre-processor module 603. After executing the 
message, control goes back to the main screen. Messages will be removed from the list if it 
now passes all the edits and audits for that mle. If the request was held for manual review, 
the User can navigate to an overview screen to review the request using screens similar to 
those in SAP sales order process. There, certain fields can be updated, such as sales area 
and delivery plant. Some fields however, can only be changed in conjunction with 
executing specific messages. For example, the customer's PO nxmiber can be changed only 
if a duplicate error is detected. For 860 change order requests, the corresponding sales 
order information can be displayed to assist the user in analysis by drilling down on the 
order number field. Additionally, a branch to the native SAP IDOC Workbench can be 
made by drilling down on the ESO nxmiber, as provided by the analyzer drill down report 
module 611. Access is now available to all ESO segments and data that may not have been 
available in customer purchase order workbench module 607. 

Page 25 starting at line 15. 

If the Z_IDCO_INPUT_PRE_PROCESS module 603 determines that a previous request 
for a customer and given purchase order is pending an acknowledgment, then the inbound 
ESO's status will be set to 'Queued for Pre-Processor' (ZO). The definition of incomplete 
in this case means that a prior ESO has not been posted by the sales order application or 
the original sales order is incomplete or blocked for any reason. This feature can be 
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disabled by changing the corresponding column in table 508 using trx ZEDI. The 
ZMOMlOl module 614 will be scheduled as a reoccurring job run hourly to process ESOs 
[are] in this status. Each request will be checked for pending acknowledgments. If the 
request is cleared for process, then control is passed to the Z EDOC-INPUT module 610 
which calls the pre-processor and manages the ESO's status and work item; otherwise, the 
request is held until the next run of the ZMOMlOl module 614. 

Page 28 starting at line 1 . 

The SAP Supplied Function Modules with User Exits module 616 functions with 
SAP function modules IDOC_INPUT_ORDERS 616 to post new sales orders, 
ICOC_INPUT_ORDCHG 616 to change existing sales [order] orders , and 
IDQC_INPUT__DELINS 616 to add FDS and JIT scheduling releases. User exits are 
available at key points in the process to allow local modifications as necessary. Module 
616 enables additional data, such as [such as] delivery plant, delivery block, fixed quantity 
ind., additional partners, and pricing reference material to be loaded into the BDC session. 
For delivery schedules, IDOC_INPUT_DELINS (not shovm) supports customer expected 
pricing condition EDIl with screen logic. No edits and audits are performed in these exits. 
These types of functions are performed by pre-processor module 603 and worked in 
workbench module 606 before this stage. 

Page 40 starting at line 6. 

For new sales order requests, the order type is determined based upon the ESO's logical 
message type (edidc-mestyp) and message code (edidc-mescod). If the message type is 
ORDERS and message code not equal to BPO (for blanket PO), then the order type is 
defaulted to 'OR' for standard order. If the message type is ORDERS and message code 
is BPO, then order type is defaulted to 'ZBO' for contract. [A-er] After the internal 
material is determined, the default order type can be overridden from the local EDI 
Configuration table/field ZEDITCFG-ZOVRAUART (rule is only applicable at material 
level). 
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Page 41 starting at line 6. 

For new sales order requests, the Sales area is determined from table EDSDC. 
The keys to this table [is] are KUNNR (Customer number) and LIFNR (Vendor number 
sent with EDI). The Customer number is the Sold-to nvmiber and the Vendor number 
represents our Sold-to nimiber at the Vendor. LIFNR is taken from the LF partner 
(ElEDKAI-PARTN) field on the ESO. If this field is not provided, the LIFNR is taken 
from the AG partner (ElEDKAI-LIFNR) field on the ESO. Together, these fields 
determine the Sales Area. For changes to an existing sales docimient, the Sales area is 
taken from the existing document. 

Page 43 starting at line 1 . 

For a new sale order request, or change to an existing order (line item add or change 
where the Customer's material nximber does not match the Customer's material number on 
the corresponding line item (using Customer's line [number),] number)), the delivering 
plant is determined from the material's sales view (table MVECE, field DWERK). For 
change to an existing sales document where the [Customer-s] Customer's material 
number does not change, the internal material is taken from the matching line item in the 
order. 

Page 56 starting at line 23: 

Verify that an FDS (Forecast Delivery Schedule) [exist] exists in table VDLB 
where ABART - ' 1' and ABRLI = [O] 0 

Page 56 starting at line 25 

If mode is append (E 1 EDP 1 0-L ABKY ='V), then any open delivery schedules are 
brought forward and appended as delivery schedules on the ESO (segment 
El EDP 16). This audit is performed only once. Open schedules are determined by 
comparing tables VBEP and VBBE. If the schedule is still open (entry is VBBE), 
then the delivery schedule is brought forward. In addition, any shipments against 
the delivery schedule [is] are also applied to the ESO (E1EDP16-FZABR) and [is] 
are subsequently available for display in the Workbench. The delta between the 
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request quantity and ship quantity is sent to PROFIT/ ATP for commit. The 
shipped quantity for a delivery schedule is derived from VBEP-WMENG minus 
VBBE-OMENG. 



Page 57 table: 



Segment-Field 


Description 


Rule 


EIEDKIO-ABRAB 


Release valid-from date 


[Earlies] Earliest 
request date 
(E1EDP16-EDATUB) 
on ESO including those 
brought forward for 
JIT 


EIEDKIO-ABRBI 


Release valid-to date 


Latest request date 
(E1EDP16-EDATUB) 
on ESO including those 
brought forward for 
JIT 


EIEDKIO-ABHOR 


JIT valid-to date 


If JIT release, then set 
toElEDKlO-ABRBI 



Page 60 starting at line 26. 

If the Input Mode is not from the Pseudo-Sales Order Workbench (implies Work 
Item already exists), a Pseudo-Sales Order Workbench Work Item is created using 
function module ['Z_Worktlow_Error_Create'] Workflow Error Create \ The Work 
Item text consists of order type and action, delivering plant, intemal material, Pseudo- 
Sales Order and Customer name. 

Page 63 starting at line 15: 

Line [item] items canceled by Customer are denoted with *D" in field XVBEP- 
UPDKZ 
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Page 64 starting at line 1 : 

The request is then sent to Pre- ATP (function module Z_IDOC_INPUT-PRE-ATP 
(313)) which populates the ATP / SAP Interface table ZATPDEM with the information 
supplied in the API (see structures and tables above) and interfaces to ATP as instructed in 
the API via MQSeries. Parameter TRIGGER_ATP ('x' send to ATP) controls if the 
request is to be sent to ATP. This is the case for all ESOs except when commits are 
present on the ESQ (from OEMLS (111), for example). Parameter RESEND_COMMIT 
is only used when an ESO is rejected by Customer and the request has been committed by 
ATP and the logical message is ORDCHG or DELINS. When RESEND_COMMIT = 
'x% then the commits on the existing order [is] are resent to ATP to replace the latest 
commits vs RESEND COMMIT = ' ' which means requesting a commit. Parameter 
TRIGGER_ZMOM103 tells ATP to raise an event to trigger the Restart ESOs in Z4 
Status (ZMOMI03) module (319) upon returning the ATP results. If the link to ATP is 
not responding in a timely maimer (currently set to 60 seconds), the Pre-ATP function is 
re-executed with the trigger set to 'x'. The ESO's status is set to 'Z4* and processing of 
the ESO is suspended until the Restart ESOs in Z4 Status (ZMOMI03) module (319) [is] 
are triggered. 

After Pre-ATP is performed, the interface table ZATPDEM is polled every 3 
seconds to see if the results from ATP have been posted. If all delivery schedules on the 
ESO have a response, then Post- ATP (Z_IDOC_INPUT_POST_ATP) is performed. The 
loop is repeated until all delivery schedules have a response or time limit exceeded (up to 
20 times or 1 minute elapsed time). If the time limit is exceeded, then the Pre-ATP 
function is re-executed with TRIGGER_ZMOMI03 set to 'x'. When the Restart [ESOs] 
ESO in Z4 Status ZMOM103 module 3 19 is triggered, then Post- ATP is performed to 
pick back up the processing of the ESO. 

Page 65 starting at line 19: 

There is some initial configuration to be done prior to using the [workbench which] 
workbench. This configuration is not covered in this document [such as] , such as: to 
configure a specific customer to always manually review [their orders, etc. Although, the] 
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its orders. The CSR has the capability to branch to selected configuration processes from 
the [workbench which] workbench. This will be covered in detail later in this document. 
The order interceptor documentation [above] , above, explains the customer-specific rules 
and configuration. 

Page 67 starting at line 19. 

If PROFIT Commit data is present, the CSR can not change any data [due to] 
because the dates and quantities are already committed for that plant. 
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Page 69: 



Delivery Schedules 


Allows the CSR to view/change the 
dates and quantities at the delivery 
schedule level. There could be 
multiple delivery schedules per item. 
Other key data is also displayed at 
this level such as the MOQ and SPQ 
quantities for that material. You may 
use the checkbox to view that 
specific item's delivery schedules or 
simply hit the Delivery Schedules 
[pushbutton] pushbutton to page 
through each one. 


Materials on EDI Trx 


A popup window displays all the 
material number(s) that existed on 
the inbound EDI transaction. It also 
shows what kind of material number 
it is in terms of customer's material 
number. Vendor's material number, 
changeable/catalog material nimiber, 
etc. 



Page 72 starting at line 14. 

This screen, as shown in Figure 7, allows the CSR to review/change all the delivery 
schedules for a line item. Both the date and quantity are modifiable fields. If there are 
multiple delivery schedules, these will be scrollable via the page up and page down. Please 
note that if you change one or more of the delivery schedules, the workbench wdll 
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automatically accumulate the total to be updated on the item quantity field. The CSR will 
be notified via an information message if this occurs. This screen also allows the CSR to 
correct or accept quantities that are out of MOQ or SPQ. Both the "SAVE" and "SAVE 
As Is" [works] work the same way by saving whatever value is currently in the quantity 
field. 
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APPENDIX B 
CORRECTIONS TO CLAIMS 



Claim 3 with amendments indicated: 

1 Claims. (Once amended). The system of claim [2]i, wherein the order 

2 interceptor comprises: 

3 ^ mean s for receiving the electronic^sales order datap^ 

4 means for translating the electronic sales order data to an internal format of 

5 the order interceptor; 

6 means for determining if an availability check is required; 

7 means for transmitting at least a portion of the electronic sales order data; 

8 means for determining if there are any processing problems associated with 

9 the electronic sales order data; and 

10 means for processing the electronic sales order data in accordance with 

1 1 business rules. 

Claim 6 with amendments indicated. 

1 Claim 6. (Once amended). The system of claim [5]4, wherein the workbench 

2 comprises: , 

3 a) means for receiving^d displayingjelectronic sales order data that ^ 

4 contains errors or is incomplete; ^ . ' 

5 b) means for displaying error messages associated with the electronic sales 

6 order data of step a); and 

7 c) means for correcting, editing, and updating the at least one database 

8 containing electronic sales order data. 



Claim 8 with amendments indicated: 
1 Claim 8. (Once amended). The system of claim [7] 6, wherein the workbench 
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2 further comprises: 

3 means for displaying the status of the electronic sales order data; 

4 means for determining i f the conf iguration rules are satisfied; and 

5 means for indicating to the order interceptor that at least a portion o f^tKe^ ^^ 

6 electronic o rder d^ is rejected. 



Claim 13 with amendments indicated: 

1 13. The system of claim [12]11, wherein the reject acknowledgment system 

2 further comprises: 

3 means for determining if the electronic sales order data was received via a 

4 transmission from the World Wide Web; and 

5 means for updating^ tlie at leas t one database.m either an ESO format or an 

6 SAP format. 



0 



BU9-99-021 



28 



McGuire Woods LLP 
1750 Tysons Boulevard 
Suite 1737 

McLean, VA 22102-4215 
(703) 712-5498 



Respectfully submitted, 




R. Coleman Jr. 
'Reg. No. 45,793 




L 



